System and method for sharing anonymous user profiles with a third party

ABSTRACT

The invention provides a system and method for sharing anonymous user profiles with a third party. In one aspect of the invention, the system shares user profiles with content servers on a mobile data network so that they may select content responsive to the user&#39;s profile. The system provides a store of user profiles for associating profile information with either a source IP address or mobile phone number, where the profile includes information on the user and the user&#39;s network usage. The system detects a user&#39;s transaction request and inspects it for either an IP address or phone number, which it uses to retrieve the appropriate profile. The system subsequently applies predetermined opt-out policies to determine how much of the user profile may be provided in response to the profile request. The system then returns the profile information such that the user&#39;s identity is masked.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/412,273, filed on Mar. 26, 2009, entitled “A System and Method forSharing Anonymous User Profiles with a Third Party,” which claimspriority to U.S. Provisional Application Ser. No. 61/039,436, filed onMar. 26, 2008, entitled “Method and Apparatus for Real-Time Brokering ofMobile Subscriber Information for Personalization of Advertising andContent,” the contents of which are incorporated herein by reference intheir entirety.

U.S. patent application Ser. No. 12/412,273, filed on Mar. 26, 2009,entitled “A System and Method for Sharing Anonymous User Profiles with aThird Party,” is a continuation-in-part of and claims priority to thefollowing applications, each of which are incorporated herein byreference:

U.S. patent application Ser. No. 12/324,672, now U.S. Pat. No.8,108,517, entitled “System and Method for Collecting, Reporting, andAnalyzing Data on Application-Level Activity and Other User Informationon a Mobile Data Network,” filed Nov. 26, 2008, which claims priority toU.S. Provisional Application No. 60/990,328, filed on Nov. 27, 2007,entitled “Method and Apparatus for Providing Contextual Per User RealTime Visibility into Mobile Content Consumption.”

U.S. patent application Ser. No. 12/324,675, entitled “Method andApparatus for Real-Time Collection of Information about ApplicationLevel Activity and Other User Information on a Mobile Data Network,”filed Nov. 26, 2008, which claims priority to U.S. ProvisionalApplication No. 60/990,328, filed on Nov. 27, 2007, entitled “Method andApparatus for Providing Contextual Per User Real Time Visibility intoMobile Content Consumption.”

U.S. patent application Ser. No. 12/324,671, now U.S. Pat. No.8,195,661, entitled “Method and Apparatus for Storing Data onApplication-Level Activity and Other User Information to EnableReal-Time Multi-Dimensional Reporting about User of a Mobile DataNetwork,” filed Nov. 26, 2008, which claims priority to U.S. ProvisionalApplication No. 60/990,328, filed on Nov. 27, 2007, entitled “Method andApparatus for Providing Contextual Per User Real Time Visibility intoMobile Content Consumption.”

U.S. patent application Ser. No. 12/324,611, entitled “Method andApparatus for Real-Time Multi-Dimensional Reporting and Analyzing ofData on Application Level Activity and Other User Information on aMobile Data Network,” filed Nov. 26, 2008, which claims priority to U.S.Provisional Application No. 60/990,328, filed on Nov. 27, 2007, entitled“Method and Apparatus for Providing Contextual Per User Real TimeVisibility into Mobile Content Consumption.”

BACKGROUND OF THE INVENTION

The present invention relates generally to mobile advertising and morespecifically to personalized behavioral targeting of mobileadvertisements.

TECHNICAL FIELD

The present invention relates generally to mobile advertising and morespecifically to personalized behavioral targeting of mobileadvertisements.

DESCRIPTION OF THE RELATED ART

Mobile data usage is increasing, due to the availability of higher speednetworks, more capable and advanced devices, and increasing trendtowards operators offering flat-rate data plans. As a result, there is agrowing momentum towards using rich media content on mobile devices.This opens up a huge possibility of advertising and personalizationaround this mobile content. What makes mobile advertising even moreattractive than other digital advertising on the Internet is that phonesare highly personal and mobile devices. In other words, a phone isassociated with a specific individual (unlike a “family” PC) and travelswith the user (unlike the home or work PC being used in specificenvironments). As a result, there is a huge potential to targetadvertisements to a specific user through personalization based ondemographics, usage patterns, and location. As the user moves todifferent places, the advertisements can be tailored to the location todeliver ads that are very relevant to the location. In addition, the adscan also be targeted to match the user's behavior, based on history aswell characteristics of the user's device and network. For instance, itis possible to serve ads based on past history of transactions orinterests. Further, since a mobile user often uses several applications,ads can be targeted across applications such as SMS, Web browsing,Video, Voice, Search, etc. Also since the mobile is a ‘communication’device, it is possible to infer communication networks around a user toinsert appropriate ads across a community of users. Other dimensionsinclude the user's tariff plan—for instance, post paid users withunlimited data plans are attractive for different types ofadvertisements than a prepaid user. This concept of personalizationbased on user-level mobile information is referred to as “MobileBehavioral Targeting”.

The state of Mobile Advertising today does not allow suchpersonalization since mobile information cannot be effectivelyleveraged. The data required for such personalization exists in silos inthe mobile network. There is a lack of techniques to correlate the dataacross different dimensions. Further, there is also no known methodologyfor analyzing this information to determine the best parameters to befed to get the best targeting and for inserting this information, inreal-time, into existing applications. In addition, privacy issues needto be adhered to. The preferred embodiment of the invention describes amethod to enable such mobile behavioral targeting, while maintainingprivacy.

Prior art can be grouped into two categories: (a) internet-stylebehavioral targeting (b) mobile ad networks and campaign managementplatforms.

Behavioral targeting has been explored for on-line PC users, but thosetechniques don't apply in the context of mobile targeted ads because newtechniques are required to capture the information required forbehavioral targeting in the mobile world. The preferred embodiment ofthe invention describes methods to capture relevant mobile specific dataand to correlate it to generate targeting data.

The mobile advertising platforms today are in their early stage wherethe focus is on creation of campaigns and not on targeting. As theseevolve into targeting, they need new methods to insert ads into themobile applications. Existing methods used on the internet don't apply.The preferred embodiment of the invention describes methods to insertthis targeting information into different mobile applications fortargeting.

These two aspects of the challenges in the prior art are described indetail next.

Challenges with Extending Internet-Style Targeting for Mobile:

Many of the standard PC approaches used on the Internet today (e.g.Tacoda, Revenue Science, AlmondNet) track user behavior on the networkthrough cookies, action tags, and clickstream information for a set ofparticipating publishers. They collect information obtained from cookiesand action tags from participating publishers and perform click streamanalysis to get information about users. These profiles are then usedfor targeting, typically by passing data through cookies. Such a cookiebased tracking and targeting approach doesn't work on mobile networks.Cookies can't be generalized across all mobile devices. Many of thenon-smartphone devices don't support cookies. Further, cookies on mobiledevices are often deleted or stripped by gateways. Also, the informationused by these internet targeting approaches is restricted to usagehistory for the set of sites they track. Not only are they limitedbecause of the set of sites, but they also don't layer in other piecesof information such as location or demographics because this data is notusually accurately available for the Internet. Demographics informationaccuracy depends on their heuristics or subscriber disclosure—which maynot be very accurate. Some point services (e.g. Quova Geopoint, DigitalEnvoy Geo-Intelligence, or Digital Island TraceWare) map IP addresses tolocation, but these techniques don't work on mobiles since often timesmobile networks mask IP addresses and user locations keep changing, sostatic IP addresses are not relevant.

There are other recent players that are addressing behavioral targetingon the Internet through network based solutions—e.g. FrontPorch, NebuAd,Project Realto, etc. These approaches work with ISPs to monitor all usertraffic and then correlate accesses to generate user behavioralprofiles. While these approaches eliminate cookies, these approaches arerestricted to the usage dimension and don't consider other parameterssuch as location. Also, these tend to be limited to Web applications,and don't extend well across mobile applications.

Thus, in general terrestrial internet approaches don't work on themobile since techniques used in the PC world for getting furtherinformation through client side scripts and cookies etc. are notuniversal on mobile phones. Further, mobile approaches can takeadvantage of other information that is unique to mobiles, such aslocation and precise demographic data. Since this information is notavailable on the PC, the internet specific approaches don't use thisdata.

Challenges with Existing Mobile Advertising Platforms and why they Don'tdo Mobile Behavioral Targeting:

Existing mobile ad platforms (e.g. ThirdScreen Media (AOL), AdMob,Rhythm New Media, Millennial Media, DoubleClick, Amobee, etc.) arefocused on a methodology to create ad campaigns and deliver basic ads.These ads are usually either contextual or based on some basic data. Forinstance, a contextual ad relies on the context of the page that isbeing viewed—it is not targeted to the specific user. In some cases, acarrier may provide some basic data such as demographics to a subset ofsites. In this case, the ad can be targeted based on this limited data.However, to achieve the full potential of targeting such a white-listapproach is not sufficient. For one, only limited data is available thisway. Second, this approach also suffers from privacy problems. In orderto accomplish behavioral targeting, ad networks need richmulti-dimensional targeting info. This data is within the mobile networkand requires technologies to collect, mine, correlate, and broker thisdata securely. The preferred embodiment of the invention describes amethod to provide additional information (e.g. location, demographics,usage history, etc.) to the ad selection process so that ads can bebetter targeted to the user. The preferred embodiment of the inventionleverages the data collection techniques described in U.S. applicationSer. No. 12/324,671, U.S. application Ser. No. 12/324,672, and U.S.application Ser. No. 12/324,675.

SUMMARY

The invention provides a system and method for sharing anonymous userprofiles with a third party. In one aspect of the invention, a systemshares user profiles with content servers on a mobile data network sothat they may select content responsive to the user profile. The systemprovides a store of user profiles for associating profile informationwith either a source IP address or mobile phone number, where theprofile includes information on the user and the user's network usage.The system then detects a user's request for a transaction with acontent provider and inspects the request for either an IP address orphone number, which it uses to retrieve the appropriate profile. Thesystem subsequently applies predetermined opt-out policies to determinehow much of the user profile may be provided in response to the profilerequest. The system then returns the profile information such that theuser's identity is masked.

In another aspect of the invention, an advertisement server uses theuser profile to select advertising content to provide to the user'smobile device.

In another aspect of the invention, the source IP address anddestination address for a transaction are detected and associated with auser session. The session ID is detected in response to the transactionrequest, and the content provider makes a profile request using thesession ID to identify the requested profile information.

In another aspect of the invention, the source IP address anddestination address for a transaction are detected and the contentserver replies to a user request with a cookie message. The cookie isdetected and associated with the user profile, and the content providermakes subsequent profile requests using the cookie to identify therequested profile information.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 shows the operational flow in the UBP platform;

FIG. 2 shows the Platform Architecture for the UBP Platform

FIG. 3 shows the general mobile network architecture

FIG. 4 shows the deployment of the brokering platform within the contextof a mobile network

FIG. 5 shows the details of the deployment of the brokers and monitorscomprising the brokering platform

FIG. 6 shows the operational flow of the brokering platform

FIG. 7 shows the different dimensions of user information collected forMobile Behavioral Targeting;

FIG. 8 illustrates the concept of Mobile Behavioral Targeting with thehelp of specific examples;

FIG. 9 illustrates the targeting logic used to determine the targetinginformation

FIG. 10A illustrates current approaches for mobile advertising and FIG.10B shows how Mobile Behavioral Targeting can be applied to thisarchitecture

FIG. 11 illustrates how Mobile Behavioral Targeting can be used across arange of applications;

FIG. 12 A-E shows the how subscriber behavioral information is insertedin Web traffic

FIG. 13A illustrates an approach for Mobile Behavioral Targeting forWeb/WAP applications, in conjunction with an external ad network;

FIG. 13B shows the specifics for how the information is passed backwhere sessions are tagged by session ID;

FIG. 13C shows the specifics for how the information is passed backwhere sessions are tagged by cookies;

FIG. 13D shows the operation of an Ad system without UBP;

FIG. 13E shows Web targeting with UBP hosting Ads;

FIG. 13F shows Web targeting with external Ad server hosting Ads;

FIG. 14 shows a System Deployment Architecture with and without UBP inoperators;

FIG. 15 illustrates an approach for Mobile Behavioral Targeting forWeb/WAP applications, with an integrated Ad Network;

FIG. 16 shows targeting in non-mobile pages with mobile information;

FIG. 17 illustrates an approach for Mobile Behavioral Targeting forVideo applications;

FIG. 18 illustrates an approach for Mobile Behavioral Targeting throughcaching;

FIG. 19 illustrates an approach for Mobile Behavioral Targeting for SMSapplications;

FIG. 20 illustrates an approach for Mobile Behavioral Targeting forApplications through an API;

FIG. 21 illustrates an approach for Mobile Behavioral Targeting inconjunction with 3^(rd) party in-line gateways;

FIG. 22 shows the insertion into a voice based application;

FIG. 23 illustrates how a carrier-centric ad exchange can be built ontop of the existing UBP solution;

FIG. 24 shows how the UBP fits within an existing Ad architecture;

FIG. 25 shows the architecture for a system that can be deployed withclients, outside a carrier network;

FIG. 26 shows the usage flow for campaign management.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

Preferred embodiments of the invention provide a brokering platform thatnon-intrusively provides targeting information to mobile applicationsand advertising platforms. The brokering platform collects data from amobile network, correlates to generate enriched user-level profiles, anduses these profiles to provide targeting information to differentapplications and advertising platforms.

The preferred embodiment of the invention describes an approach to getaccess to this unique mobile-specific information and to use it toeffectively achieve mobile behavioral targeting within an existingecosystem of handsets, mobile infrastructure, and content servers aswell as within existing business processes applied in the mobileoperator and content provider worlds. Among other things, the designallows the brokering platform to be used for:

-   1. Enabling a mobile operator to securely exchange brokering data    with third party application and content providers and advertisers    without compromising user privacy;-   2. Brokering targeting information for enhancing the effectiveness    of mobile ads through targeting. Ads can be targeted into multiple    apps such as web, video, messaging, and gaming without changing the    applications or processes used in the ad servers;-   3. Operating a carrier-specific ad exchange that takes into account    mobile-operator specific capabilities and data;-   4. Using mobile targeting information to target ads on PCs;-   5. Using targeting information to personalize user content and user    experience. For instance, on-device portals can be tailored to users    without their having to customize it periodically. Content providers    can provide content unique to user's locations, etc. This user    segmentation can also be used to better target existing applications    and services to mobile users.

Overall Flow for Mobile Behavioral Targeting:

The steps for such targeting are described next and described in FIG. 1:

-   1. Capture (110): The mobile subscriber data across applications and    dimensions is captured. This capture is continuously happening in    real-time. As time progresses, further information is available and    the data contains additional information and this can be used to    generate historic information. Data collection techniques for the    preferred embodiment of the invention are described in U.S.    application Ser. No. 12/324,671, U.S. application Ser. No.    12/324,672, and U.S. application Ser. No. 12/324,675;-   2. Correlation (120): The information collected from different data    fields is correlated to create a rich subscriber profile as well as    historic information for usage;-   3. Transformation (130): The collected data is transformed into an    internal vector with masked user identities and saved based on    opt-out policies;-   4. Storage (140): The data is then stored in an internal database;-   5. Privacy (150): When a request for serving targeting information    comes along, the privacy policies are checked to enforce opt-out    policies;-   6. Targeting (160): The science and logic for determining the best    targeting parameters, including cross-application targeting and    segmentation is applied. This allows the user information to be used    effectively for targeting, depending on the user, policies,    application, etc. The targeting information can be used in several    ways. First, it can be used in real-time to target a specific ad.    Second, it can be used to generate a list of users for campaign    management. Third, it can also be used to target the user experience    in real-time by recommending new related applications or content;-   7. Insertion (170): The next step is to insert the selected    information seamlessly, in real-time, within applications;-   8. Audit and Settlement (180): As ads are being targeting, the    system provides a method to audit the information passed in order to    enable settlement with the advertisers or content providers; and-   9. Reporting (190): The platform continues to provide real-time and    audit reports on the application level behavior as well as    information shared. These reports can also be used by operators to    improve their network policies, analyze applications, etc. For    instance by identifying that a specific application is used more, it    can be given higher priority for advertising. The app can also be    moved to an on-deck portal for better access.

Platform Architecture

FIG. 2 shows the brokering platform architecture. The platform comprisesseveral modules:

-   1. Data collection: This module 210 comprises different adaptors to    collect information from the mobile network. New adaptors and data    collection approaches can be easily added into the platform. Example    adapters include real-time Web/WAP stream monitoring (output of    GGSN, HA, etc.), location data connectors, subscriber databases    (e.g. LDAP), SMS/MMS traffic, USSD traffic, voice CDRs, WAP logs, or    logs from specific applications and Value Added Service Platforms    (e.g. ringtones, wallpapers, etc.). Another type of adapter is one    that collects data from clients on phones, e.g. a shim or a    brokering client on the handset;-   2. Correlation Engine: This module 220 takes the data from different    adaptors and generates a single correlated vector that is stored    into the database. Different data modules are often identified    through different IDs, including mobile phone number, user ID, IP    address, etc. The correlator maps these identities and generates a    vector with user information. The data is also stored such that    user-specific information can be masked;-   3. Targeting and Insertion: This module 230 determines and applies    the targeting logic and privacy policies for advertising. It also    includes adaptors to pass the anonymous vector to other    applications. This is also a scalable design in that new    applications and forms of information exchange can be easily added    into the system. Specific insertion mechanisms are described in the    later part of this document; and-   4. Reporting and Analytics: This module 240 generates reports to    audit information exchanged, performance, etc. It also includes    application level monitoring information so that the operators and    advertisers can target appropriately. The module also includes a    rich policy language so that advanced specific queries can be    generated on the logic. The Application Targeting logic allows    real-time analytics on the data for dynamic segmentation of users.

In one implementation scenario, the monitoring and data collectionfunction can be separated out from the data analytics and exchangefunctions. In this case we refer to the monitoring function as the UMPand the brokering and related functions as UBP. In some cases all thefunctions could be implemented on the same platform.

Deployment

The general context of a mobile network is shown in FIG. 3. A genericarchitecture is shown, which could map to either GSM or CDMAtechnologies. Mobile devices connect through the base stations and themobile data core through a router such as a Gateway GPRS Serving Node(GGSN), Packet Data Serving Node (PDSN), Home Agent (HA) GGSN/PDSN/HA310. The GGSN is in a GSM network. In a CDMA network, the devicesconnect through a PDSN/HA. In case the network is based on simple IP,there may not be a HA but just a PDSN. The mobile data request may besent to content and application servers outside the mobile network 320(this is often referred to in the industry as off deck’ or ‘off net’) orto an operator portal 340 via a WAP gateway 330. The data request mayalso be to application servers 350 which may be internal or external tothe operator. The data at the output of the GGSN 310 thus comprises alltypes of data applications, including Web, WAP, video, audio, messaging,downloads, and other traffic. In addition, the mobile data network has asubscriber database 360 that manages subscriber information. This couldalso be a Customer Relationship Management (CRM) database or anAuthentication, Authorization, and Accounting (AAA) server. The networkalso consists of a location platform 370. Other types of data sourcescould be Short Messaging Service Center (SMSC) 380 that managesmessaging traffic. The Billing System 390 manages the billinginformation for user services.

FIG. 4 shows the conceptual deployment of the brokering platform 410within the mobile operator network. It is deployed in a non-intrusivenon-inline architecture that collects data off the routers or messaginggateways.

Capture

FIG. 5 shows how the information itself is collected by the brokeringplatform. The brokering platform sits in the mobile network and throughadapters (called Collectors 510, 512, 514, 516) collects informationfrom multiple sources—content level information from the GGSN/PDSN/HA310 output, location information from LBS platforms, subscriberinformation from subscriber databases, Messaging traffic from SMSC/MMSC,USSD, etc. Some feeds are tagged with IP address (e.g. GGSN output)while some feeds have a phone number (LBS). The Collector determines amapping of IP address and phone number and sends a correlated vector tothe Data Manager 520. The Data Manager gets the correlated informationfor a specific stream. It also maintains a historic database which keepstrack of past transactions at a high level. Other feeds such as socialnetworking contacts, CDRs for voice call records, SMSC feeds, etc. arealso possible. In addition, logs from applications such as ring tonedownloads can also be used. This information is aggregated within thebrokering platform to store a rich database for user information. Thebrokering platform includes the collectors and brokers 520, 530, 540,550 placed in conjunction with each Collector. The brokers manage theprocess of getting transaction information, retrieving targeting data,and sending the targeting info to the appropriate application. In analternative architecture, the brokering platform can also sit outsidethe mobile network and collect information through distributed agents onmobile devices. A hybrid approach that combines both client and networkbased collection is also possible.

Operational Flow of the Brokering Platform

FIG. 6 shows the operational flow of the brokering platform. There aretwo aspects to the operation of the brokering platform. The firstprocess runs continuously and builds user profiles within the DataManager. The second process retrieves a run-time transaction ID when arequest for real-time targeting information arrives, retrieves detailson the transaction and passes appropriate information to enabletargeting ads or applications. These steps are described in more detailbelow:

-   1. The collector captures network data for different applications in    step 610;-   2. The data off the wire is filtered in step 615;-   3. The collector also captures phone numbers and correlates them to    IP addresses in step 625;-   4. At this point other user information associated with the phone    number, such as demographic profiles and location data is also    collected in step 620;-   5. The correlated information is transferred to a centralized data    manager in step 630;-   6. The centralized data manager also receives data from other    sources in step 640;-   7. The data is then enriched with other metrics in step 650. At the    end of step 7, the enriched event for that user for that transaction    is obtained; and-   8. The user transaction is then used to update the user profile in    the database in step 660.

Steps 1-8 above run continuously and update the user profile. The userprofile contains information including sites visited, locations visited,usage, etc. It also includes demographic information. This informationcan be mapped into specific segments that can be further defined basedon these parameters. An example of a user profile is <phonenumber/masked ID><device><demo group><types of destinationsvisited><types of locations visited><usage pattern>

-   -   The phone number of masked ID is used to identify the user. For        privacy reasons, a masked or hashed ID may be used to store user        data;    -   The device information describes the type of device—smartphone,        PC, featurephone etc, OS type, and capabilities, such as touch        screen/keyboard support. This is usually not updated regularly;    -   The demographic group specifies attributes such as age, gender,        service plan type, etc.;    -   Types of destinations visited. This includes a list of last few        destinations, along with typical patterns such as sports        categories, entertainment, etc. This is typically stored as the        top few categories and their frequency of visits;    -   List of locations visited is used to identify mobility patterns,        e.g. user moving within local area, cross country, etc.;    -   Other pieces of information could also be added to the profile,        as described in step 6. Examples of this could be billing data        or spending data, by integration with billing systems. Other        possible data sources include data from clients on handsets. For        instance, a client on the phone could describe the activity off        the mobile network, such as on Wi-Fi networks. Other information        can also be inferred, such as usage patterns        (heavy/medium/light, day or weekend use, more in morning vs.        afternoon, etc.).

Several fields are relatively static e.g. device type, while some fieldscould change quite frequently. For instance, the locations visited orthe categories of destinations visited evolve over time. The types ofdestinations can be segmented more granularly over time as well. Forinstance, in a first cut, destinations may be categorized as finance andentertainment. In a next phase, destinations may be finance->equitiesand entertainment->movies. This allows more specific data to be compiledon user behaviors. This concept of continuously building profiles makesit possible to transparently build more accurate profiles over time.

Although the phone number and IP address are used to build this profile,the phone number itself is not stored into the system. In effect, amasked ID (such as a one-way hash) can be used to build the profile. Asa result, no user-identifiable data is stored into the system.

While the entire profile contains a number of characteristics of userbehavior, not all parts of the profile may be shared with the upstreamadvertisers or publishers. For instance, if a carrier has a ‘premium’deal with a publisher, they may share all the data. In some cases, acarrier may only share location or usage history data.

1. These data points are used to build a user profile. At the time ofbrokering, the profile data is extracted, along with current info suchas location to build a profile that is exchanged upstream. The exactamount and type of information exchanged, along with the format isflexible and depends on the advertiser receiving this information. Whena user requests a transaction (e.g. accesses a web site or videoapplication), the application request is seen on the wire by thecollector, in step 670.

2. The collector passes the IP address and corresponding request to thebroker in step 675

3. The broker then looks up the user profile for that user from the datamanager in step 680. The format of the profile is flexible. In oneembodiment the profile could be a vector with details such asdemographic segment, location, type of user, etc.

4. The broker passes the profile information to the application in step685. Details on how this information can be passed to differentapplications are provided later in this section.

5. The delivery of the ad is recorded for future tracking and reportingin step 690.

Data Dimensions and Correlation

FIG. 7 shows the different dimensions of information captured forgenerating targeting information:

-   1. Context 700: This is the request for a specific data. It could be    a HTTP or WAP request for web traffic, RTSP requests for media, SMSC    feeds for messages, or other protocols for other applications. While    the description is focused on data applications, the context also    applies equally to voice applications. The context gives details for    the specific request. Sometimes it can be inferred from the    destination address, but sometimes further information from the    content source itself is used.-   2. Location 720: This includes location information for the user at    the time of the request. The location information could be at    different granularities, including exact address, cell sector,    triangulation, etc. often is available in geocoded data from the    mobile network. The location data (e.g. cell ID) is extracted from    the RADIUS message at the GGSN/PDSN. The UBP can convert this to a    physical location, zip code, DMA code, etc. depending on the    granularity desired.-   3. Demographics 740: This includes subscriber information. The    information can be either available in raw format from the mobile    operator or in some sort of groupings such as “male, 15-25”, “male,    35-50, middle income”, etc. If processed information is not    available, the UBP can categorize information before storing it    internally. Other demographic information also includes service plan    type e.g. prepaid or postpaid. The location data can be extracted    either from a second database, indexed by the mobile number, or it    could be extracted from a RADIUS feed, if inserted by some carriers.-   4. Network Info 730: The instantaneous speed can be determined to    send specific information for applications and content to be    tailored appropriately. The network speed is typically retrieved    from RADIUS parameters.-   5. Device Info 710: This information is mostly available from the    User Agent (UA) request, but can also be collected and stored for    correlation purposes.-   6. This is useful to tailor content to device capabilities and also    to detect the type of user to gauge type of apps.-   7. Voice CDRs, SMS CDRs: Information from other application sources,    other than data may also be useful. For instance, voice CDRs give    calling patterns so it is possible to target based on a specific    ‘community’. Simple information such as the ‘friends and family’    plan data may also be useful for this type of data. The core idea    being that it is possible to market certain products and items to    specific groups of people.-   8. Usage History: The UBP can also derive information about the    usage history of a use to do trend analysis. This includes the types    and categories of destinations accessed.-   9. Presence: Knowing the user's presence information allows    additional information to be inferred to customize the experience.    Presence information from Presence servers can be used to identify    the user's status, i.e. whether or not the user is active on a    device, or which device the user is active on if he is connected    through multiple devices.-   10. Application Logs: Logs from applications such as ringtone    servers, ringback tone servers, wall paper or other commerce    platforms can all be obtained to get usage information.

Note that this is an example list, other parameters can also be added.An embodiment of the invention describes a scalable platform whereadditional adapters can be added to collect specific feeds and a datamining algorithm that is flexible to operate on new feeds. Also, as moreinformation is collected, the internal data stored becomes more and morerich and can do more sophisticated historic patterning and trending.Since different feeds change at different frequencies the platform hasthe ability to configure how often each adapter checks for feeds,whether it is push or pull, etc. For instance subscriber informationdoes not change much, whereas location information changes on a persession basis, whereas stream information changes for every accessrequest. By adjusting the frequency and nature of data collection, theload on the mobile network can be minimized.

This information is all collected and aggregated and a resultant outputvector is available that characterizes a specific outgoing stream.

An embodiment of the invention can collect and monitor profiles acrossthese different dimensions. Internet based systems don't have access toall these different feeds accurately and so cant be used to build aholistic profile. As mentioned earlier, location is very granular inmobile networks. By sniffing data from within a network, it is possibleto build a profile across all the sites the user accesses, unlike in aon-line world where the data is restricted to the sites the publisher isaccessing. Also, the mobile world provides access to a range ofdifferent applications such as video, messaging, etc. which help build amore holistic view of the user.

Targeting Logic

FIG. 8 shows some examples of Mobile Behavioral Targeting. Example 1shows how advertising can be tailored, based on “Location”. Forinstance, user A 810 accesses a news site from his mobile at the airport812. At this point, an ad corresponding to a Car Rental Coupon 816 couldbe served since he is highly likely to be renting a car at the airport,especially if we know that the user is at a different airport than his‘home’ location. Later, if the same user browsed the same site from aMall 814, at lunch time in the specific time zone that he is in, it ispossible to serve an ad for a Restaurant's lunch special 818. In thisexample, the specific information of user's current location, homelocation, time zone in current location, etc. is available from a mobilenetwork.

Example 2 in FIG. 1 shows targeting advertisements based on ContentUsage and History. For instance, user A 820 accesses a video for ‘bestluxury cars of the year’ 822. In this case, the content site knows thekeyword for the content to be ‘automobiles’ and today would serve an adfor an Auto Magazine 823, for instance—this is the classic “contextual”advertising technique. However, if the same user then goes to a newssite 824, it would now be possible to serve another ad for an AutoMagazine 825. Similarly if the same user now goes to a “Toyota” web site826, it is likely that “Ford” provides the highest premium ad and wouldbe displayed 827. This cross-targeting allows much more powerful brandmessaging. However, if this historic behavioral information is notavailable, it is not possible to accomplish this. Such cross-domainhistoric information can only be obtained from the mobile network (ormobile device) since it is the one place that has visibility into allthe traffic going through the network. Such cross-site information isnot available at a content server. One way to achieve this is throughcookies, but that requires dependencies on the client and also requiresparticipation from content providers. What's unique on the mobile isthat this can be accomplished without any dependencies. Further, thesame example can be further extended in the mobile scenario where theuser also sees an automobile related ad in a SMS message, thus tying incontent history across applications.

Example 3 in FIG. 1 shows targeting advertisements based on“Demographics”. In this case, two users A and B go to the same contentsite. It is known, however, that user A 830 is a female with a certainincome level. In that case, an ad for women's apparel 837 might bedisplayed. If user B 832 is a male with an interest in sports, an ad forGolf 838 might be displayed. This targeting is possible due todemographic information that is available on the mobile network, withouthaving to infer from user behavior.

While each of these examples described a few dimensions used intargeting, it is possible to use combinations of dimensions to create amuch more context specific advertisement. For instance, in Example 1,the Mall Ad displayed could also be related to a specific clothing orsports item related to the user, thus combining location anddemographics.

Another example of targeting is to analyze the behavior of a user acrossapplications. For instance, it is possible to analyze behavior acrossringtones, wallpapers, SMS, etc. A user who buys jazz ringtones andcertain types of wall papers might be a candidate to offer new musicdownloads in that category. It is also possible to analyze SMS trafficfor user behavior and to correlate to other dimensions. For instance,notifications from specific short codes can be used to determine userbehavior. A user getting notifications from financial institutions andgolf scores might be of a certain demographic, for instance.

FIG. 9 shows the different parameters and their possible importanceacross different applications. The following are meant to be examplesand other algorithms can also be derived based on similar parameters.Consider specific parameters: location, demographics, contentinformation, usage history/behavior, and community information as sampleparameters.

a. Web: With a Web application (e.g. browsing on a news site), thelocation of the user, the demographics, as well content history would beuseful to target an ad. For instance, knowing that a male of 25-35 yearsis at Boston airport, and that the user has been looking at Car sitesgives a good idea that a sports car related ad may be most relevant forthis session. In this case, the community data may be less relevant.

b. Video: Video characteristics are likely to require similar parametersas web traffic.

c. Messaging: In the case of operational messages or promotionalmessages, knowing demographics or history or location is useful totarget the information. In the case of peer to peer messages, knowingthe community of users is also helpful to target advertising.

d. Search (Web or Voice): When the user is requesting a search for aspecific item, knowing the user's location and demographics would bevery helpful to target the ad. So if he searched for pizza, it ispossible to pop up an ad for the local pizza place—instead of a nationalnumber.

e. Gaming: With a gaming application, knowing who the user is and wherehe is would be useful for targeting. Further, knowing some history wouldalso be relevant to targeting an ad.

f. Social Networking: In the case of social applications such asmessaging or other specific social networking apps, knowing thecommunity is helpful to target a message to a group of similar users.This can also be used to target a specific application across a group ofusers—e.g. video share app can be targeted to a group of users thatseems to communicate a lot on the phone or via messaging.

g. Voice ringtones: In the case of ring back tones, if A calls B, hemight hear a ringback tone that characterizes something A likes. If Ccalls B, C might hear a different ring back tone. The ringtones can betailored to map user groups and interests as specific advertisements.

h. Wall papers and ringtones or music downloads: Knowing the history ofthe type of information the user is interested in helps determine whatnew applications the user may be offered.

The overall targeting logic described above can be used in conjunctionwith specific applications and partners to generate maximum value.

Some other characteristics of the targeting logic include:

-   1. Mapping users into pre-defined segments: There are generally    several preferred areas for segmenting users. As user information is    captured and evolved over time, the users can be mapped into    specific segments;-   2. Dynamically generating segments: By seeing the real-time behavior    of users, patterns of users can be derived dynamically. For    instance, if a number of users are seen to access a specific    application, it is possible to see the trends of these users in    other dimensions;-   3. Mapping users into multiple segments: As the granularity of    segmentation increases, it is possible to map a user into multiple    segments; and-   4. Dynamic creating segments: In addition to inferring segments, it    is possible to create segments through a policy language.

Privacy Approach:

As the targeting and segmentation is done, it is important to maintainuser privacy. An embodiment of the invention enables maintaining a userprofile securely, and ensuring that only relevant data is shared withappropriate privacy controls. This concept can be thought of as a‘network’ based cookie that is maintained by the service provider'snetwork. The cookie is the user's profile that is built over time.Depending on privacy policies, only a subset of this info is exchangedupstream. E.g. while the network cookie would maintain usage history,only a category can be provided to the content partner. Also, by doingthis, the user's phone number or any PII need not be exposed upstream.

The network cookie concept allows the carrier to broker targetinginformation without exposing a user. In traditional targeting, a user'scookie is maintained on a PC and is sent for targeting. In an embodimentof the invention, the user info is stored within the carrier network onthe UBP, not at the handset level. This vector can be conceivablythought of as a ‘network cookie’. During a brokering transaction, theentire profile need not be shared, and also what is shared could dependon the context. The profile info is shared in the context of thesession, and not user. For example, consider two users A and B withphone numbers N1 and N2. Example profiles would be stored along thehash, so as M1=hash(N1) and M2=hash(N2).

<M1, Northeast US, iphone, {categories=sports, news}, demo={M, 35-45,flat rate plan}>.

<M2, Northeast US, iphone, {categories=movies, video games}, demo={F,18-24, family plan}>.

Now consider user A going to cnn.com in the morning. A possible vectorexchanged with cnn could be <current location=Boston, homearea=Northeast US, device=iphone>, while a profile exchanged with yahoocould be <current location=Boston, home area=Northeast US,device=iphone, demo={F 18-24}>. In this example, cnn and yahoo couldhave different policies for amount of data available. If the same user Awent to cnn in the evening, a possible vector could be <currentlocation=Andover, home area=Northeast US, device=iphone>. In thisexample, there is no way for cnn to know that it's the same user A thatcame in the morning and evening, unless the UBP and carrier chooses totell cnn. Now if user B went to cnn also, the profile could be <currentlocation=Andover, home area=Northeast US, device=iphone>. There is noway for cnn to know A and B were different users—it only cares about howto target the users. In neither cases is the user's phone numberexposed. Instead, the profile is sent based on the context of thetransaction and user.

The preferred privacy capabilities in an embodiment of the inventioninclude:

-   1. Transaction uniqueness: When the UBP shares info upstream, it    masks the identity and specifics of the data. This ensures that a    specific vector can't identify an individual. Further, the vectors    are so generated that repeat transactions from a specific user can't    be traced back to the specific user either. This is done by passing    a unique session id describing the transaction, not the user. As a    result, the content site or application can't track the history of    the user through this ID. This is different from ‘cookies’ where    persistence is maintained on the client, thereby exposing the user    to other applications. By maintaining the user information within    the network, the service provider has the ability to maintain    privacy of user information;-   2. Data masking: Data stored within the system is also masked so    that external queries by phone number or user name won't reveal user    information;-   3. Privacy and Disclosure policies: Specific Privacy Policies    include checking whether the user has opted for targeted    advertising, determining what information is sent to which content    partner, using selective dimensions for targeting, etc.    Specifically, when the targeting information is shared upstream with    an application or content site, the policies on the user can be    checked. For instance, location data for a specific user may not be    shared upstream, while for certain users could be shared. In another    example, zip code related information may not be shared with a    specific content partner, but could be with another partner. These    policies could be based on business relations or user preferences at    a per user, per content provider level and can also be changed in    real-time;    The UBP has a number of preferred privacy controls. These are listed    below as they apply to the different steps of data collection,    profile building, and data exchange;    -   Data Collection        -   a. Data is collected off the network, and hence there is no            need to generate logs from third party applications. This            ensures that user-sensitive information is not distributed            through the network        -   b. During data collection and processing, masked user IDs            are used (through one way secure hash). As a result, no user            phone numbers need to be managed        -   c. The data collection itself supports opt-out policies for            users/URLs/IPs not to be captured        -   d. No payload is retrieved, no SSL data looked at    -   Profile building and Storage        -   a. User profiles are maintained through hashed IDs, so can't            be traced to a specific user        -   b. Solution is deployed within carrier infrastructure, so            each carrier's data is separate    -   Brokering        -   a. Data is brokered on a transaction basis, not at the user            level. Partners can access data through policy driven,            secure interface        -   b. Selective data can be exposed, depending on policies.            E.g. demo or location, even in aggregate, can be blocked off        -   c. Partners can't see other site's data    -   Technical considerations        -   a. Box is secure—no external access to the box, ftp and            other services controlled        -   b. Secure login, attached to different auth schemes-   4. Frequency Capping: It is also possible to cap the amount and    extent of user information shared across network, applications, and    providers as well as number of times this information is used. For    instance, the service provider can decide that information about    user A is exposed only Y times in a month at a specific minimum    separation, and only Z times to a specific application. These    controls can only be applied from the network.

Insertion

An embodiment of the invention describes an approach to pass targetinginformation without impacting existing applications and businessprocesses. Before we describe how to achieve mobile targeting, as way orprior art, we first describe how advertising is delivered withouttargeting and then how targeted advertising is done on the Internet forPCs.

FIG. 10A shows a known approach for inserting advertisements into Webpages on the Internet, which is also the currently used approach forinserting ads into Mobile Web pages. When a user requests content 710,the request is sent to the server. The server, in turn, contacts an AdServer 720 to determine the ad to be inserted. Typically, the ad serverselects the ad based on either the content or the keywords, in additionto the bid received from the advertisers and returns the ad or a pointerto the ad to the content server 730. The server then responds to theoriginal HTML request by including the content along with the specificimage for the ad 740, or in many cases, a link to the ad being served.

FIG. 10B shows the Behavioral Targeting approach, where the ad insertedis precisely targeted to the user. Specifically, when the Ad servermakes a selection for the ad, it takes into account additional“behavioral targeting” information provided by an optimizer 770. Whilethis general approach for “optimizing” the ad can also be used for“mobile” behavioral targeting, the “mobile” aspect differentiates it inhow the behavioral information is supplied and what is supplied asbehavioral information. Specifically, in the Internet on the PC,behavioral information is supplied via cookies. Further, the informationtypically involves some sort of PC IP address ID or user ID so that theserver can track the same user through multiple sessions. In some cases,the optimizer then uses the IP address to further query a platform likeDigital Envoy to determine the location of the user. In the case ofmobiles, as discussed earlier, cookies are not reliable and end systemsare not powerful like PCs, so other forms of passing information arerequired. Also, attributes required for mobile targeting can be muchricher. Further, mobile targeting can be applied to a number ofdifferent mobile apps, not just web browsing—for instance, voice, sms,gaming, tv, search.

FIG. 11 shows how targeting information can be fed to a number ofupstream applications. These include mobile Ad networks 1110, mobileapplication platforms such as gaming 1160, location based applications,SMS applications, messaging applications 1180, etc. It also applies tovoice based applications such as search or ring back tones 1190. Anembodiment of the invention describes an approach where once theinformation is collected, it can be sent to any application that can usethis information to either target the advertisements better or in somecases to also better target the application itself.

In addition to feeding this information to existing applications andadvertisers, it is also possible to build out an advertising frameworkitself based on this information. For instance, specific campaign rulescan be applied to determine what information is to be targeted and howand then ads can be inserted. Also, this separate advertising networkcan operate in conjunction with other ad networks where some specializedads can be served out of this network, while others are served out ofexisting networks.

When this information is to be shared upstream, specific informationabout the application, user, content provider, etc. can be considered todetermine the information shared. There is also a need for a systematicanalysis of the relative importance of some of the parameters. Also, itinvolves determining how to pass this information at a granularitydetailed enough to be of value but also high-level enough so that thereis sufficient advertising inventory that fits the characteristics.

Another aspect of an embodiment of the invention is how the collectedinformation can be provided to existing applications so that targetedads can be inserted. Existing ad insertion technologies focus on how anad can be physically inserted into the content being viewed. This rangesfrom simple banner ads on web/WAP pages to pre-rolls and banners onvideos. In the case of videos, the challenge is getting the right formatfor the ad and the content, concatenating them, and displaying them inreal-time. In the case of SMS, ads can be inserted by appending text tothe end of the text message. Since SMS has 160 characters and mostmessages are smaller, it is possible to insert ads within the extra bitsavailable in the text message. Ads can also be inserted into otherapplications such as games or IM applications. In this case, it isrequired that the application have a method inbuilt to display the ad,while an ad server determines the ad to be inserted. An embodiment ofthe invention describes a method that leverages existing ad insertiontechniques to better target the ads. Specifically, it allows for sharinginformation so the ad insertion technology can select the ‘best’ad—without changing the application or placing any demands on thedevices.

a. Insertion into Web Applications

FIG. 12 shows different approaches for passing behavioral targetinginformation for Web applications.

A. The information can be sent in-line by adding a tag to the HTMLrequest. For instance, a request http://www.xxx.com can be modified 1210to be http://www.xxx.com?gender=m?loc=123. This requires the UMP to bein-line to insert the code. Alternatively, it can work with a WAPgateway or a similar in-line to device appropriate information. The tagsare available at the content server, which can then be passed on to theadvertiser as the request is made.

B. The information can be provided out-of-band to the advertiserdirectly for a specific request. Specifically, in this approach thecontent server can generate a session tag of sorts in the HTTP responseto the client to identify the request 1220. The UMP can track thissession tag in the embedded HTML and associate with the outgoingoriginal request. The UBP can then provide the user information with thetag ID to the advertiser, who can use this to retrieve profile data1230. One limitation with this approach is that it will not provide anad for the first request since the session tag is provided only in theresponse of the first page. Specific approach is described later in thedocument.

C. In another form related to B, the server can request additionalinformation for a specific user 1250 once it receives the HTTP request.The UBP can respond by passing on the optimization parameters. Theserver then passes this information to the advertiser when it makes arequest for the ad. This approach requires a specific way to identifythe request seen by the UMP on the outbound stream and the one that isreceived at the server—especially when there could be NATs or proxiesalong the way. Specific approaches are described later in the document.

D. The information can be provided through a client side module. The UBPclient can have a presence on the mobile devices. The UBP server candetermine the information vector for a specific user and send it to theUBP client on the handset 1260 (this does not require the client to runany scripts to determine the tags). The handset client functions as aSHIM on the handset, and inserts the information into the outgoing HTMLrequest at the HTTP level (or into other applications). This approachdoes not require the UMP to be in-line, but requires a client to bedistributed to the handsets.

E. Other approaches are possible, where the server may request a cookieto be set. The UMP sees the request for a cookie to be set for aspecific user. While it can't be assumed that the cookie is set in thedevice, the UMP can maintain the cookie for the user. The UMP can insertthis cookie, populated with appropriate information, through an in-linearchitecture 1270.

Specific details for approaches B/C and E along with another novelapproach are described next.

FIG. 13A shows integration with a web browsing application working inconjunction with a 3^(rd) party ad network. As shown, the publisherinserts some code 1330 on behalf of the UBP. This code is invoked when arequest comes in 1320. The code queries the UBP server for parameterscharacterizing the request 1322 and receives response 1324. This thencalls the ad server to select the appropriate ad 1326. In this preferredapproach, the originating request from the device is correlated with therequest received at the content server. Typically the mobile networkmasks the source IP address at the destination so the IP address seen atthe source and at the destination are not the same. To address thisproblem, two approaches are described, one that uses the HTTP serversession ID for correlation, and the other which uses a cookie. Sincecookies are not ubiquitous, the session ID presents a generic approach.FIG. 13B shows the integration with a session ID.

Correlation with Session ID:

-   1. Phone makes a request for a session with a content server 1340.    The request has associated with it, an IP address and a destination    address-   2. The UMP captures the session and tracks the source IP and the    destination address 1341-   3. The content server is modified to return for all the URLs on this    page, an attached session ID associated with this request 1342. (The    content server creates this unique session ID)-   4. The UMP monitors the response and sees the session ID embedded in    the URL for the response to the originating IP address. It stores    this session ID with the other information for this user 1343. It    also collects other data for this user, including user and location    and keyword information. The UMP now has associated the outgoing IP    address with the session ID from the content server-   5. The user makes a second request to the same destination. 1344-   6. Before delivering the HTML response, the content server requests    the UBP for parameters for this user characterized by the session    ID. 1346-   7. The UBP returns the parameters for the session ID 1347-   8. The content server can now embed an appropriate ad or modify the    content in the response before sending the HTML. 1348-   9. This approach requires the content server to create and append    the session ID-   10. FIG. 13C shows an alternative approach that uses cookies for the    purpose of correlating the IP address.

Cookie-Based Correlation:

-   1. The user makes a HTTP request to the server 1349-   2. The UBP tracks the user with IP address and destination 1350-   3. The server sees that a cookie is not set and sends a set-cookie    request 1351-   4. The UBP tracks the cookie and appends it to its internal    information for this user 1352-   5. The user makes a second request, now with an embedded cookie 1353-   6. The server queries the UBP for information using the cookie as    the query term 1355-   7. UBP returns parameters associated with user 1356-   8. The server then responds with an appropriate ad 1357.

Another design that does not require cookies or session IDs is describednext. In order to describe how an embodiment of the invention works, wefirst describe the operation of such a system without the technologydescribed in the embodiment of the invention, as shown in FIG. 13 D:

-   1. An Advertiser (e.g. Ford Auto) creates its ad (e.g. ad123) and    hosts it on an ad server (e.g. doubleclick.com). The advertiser    works with a content server partner (e.g. cnn.com) and gives it    information that the ad123 should be displayed X number of times,    based on the campaign it is working on. The Advertiser gives the    content partner a pointer to the ad as ‘adserver.com/ad123’ (1358)-   2. User requests the web page at cnn.com 1359-   3. The content server computes which ad is to be displayed, based on    its own advertising logic or through the ad server's logic 1360-   4. The content server returns the HTML response to the user with an    embedded link pointing to an ad on adserver.com 1361-   5. The browser on the device makes a request to adserver.com to    retrieve the ad 1362-   6. The ad server returns the image of the ad 1363-   7. The browser displays the requested content page, including the    embedded ad 1364.

Note that in the approach used today, there is no way to ‘target’ the adto the requesting user because the user's unique identity is notavailable at the content server.

An embodiment of the invention describes an approach where the ad can betargeted to the user. Note that while the approach describes targetingan ad, the same technology could also be used to target the contents ofthe page displayed as well.

The approach described in an embodiment of this invention entails thecontent server requesting the ad from ad.umber.com. The ad logic and adcould be implemented on ad.umber.com if the carrier is managing its ownad network. Alternatively, the ad logic and ad hosting can be managed atthe ad server, with the UBP providing the parameters to the ad logic atthe ad server. This approach requires only a one-time change at thecontent server requesting the ad from the UBP. In the preferredapproach, the UBP sits in the mobile network and hence has access to theuser's unique IP address, which it uses to derive behavioralinformation. Depending on where the ad is physically hosted, theapproach can be implemented in different ways:

Assuming the ad is hosted on the ad server and the ad server manages theadvertising logic, the approach works as follows (FIG. 13 E):

-   1. The Advertiser (e.g. Ford Auto) creates its ad (e.g. ad123). The    ad is hosted at the ad server adserver.com as is done today. The    advertiser works with a ad that the ad123 should be displayed X    number of times, based on the campaign it is working on. Specific    ads are hosted on adserver.com 1365-   2. User requests the web page at cnn.com 1367-   3. As the user request goes out, the UBP monitors the IP address of    the user and retrieves the parameters associated with this user 1368-   4. The content server returns the HTML response to the user with an    embedded link pointing to an ad on ad.umber.com 1369-   5. The browser on the device makes a request to ad.umber.com to    retrieve the ad. The request arrives at ad.umber.com from the user's    device with the original IP address (since the UBP is sitting within    the carrier network) 1370-   6. The ad.umber.com module in the UBP queries the UBP for parameters    for the IP address 1371-   7. The UBP returns the parameters characterizing the request (e.g.    age, demographics, location, behavior history, etc.) 1372-   8. The ad server selects the ad 1373 and returns the image to the    browser 1374-   9. The browser displays the originally requested web page with the    appropriate ad embedded in the page 1375.

Assuming the ad is hosted on the UBP along with the ad selection andcampaign management logic, the approach works as follows (FIG. 13 F):

-   1. Umber works with the content provider that ads should be managed    by Umber and all ad requests point to ad.umber.com. Umber works with    advertisers to get ads, e.g. Fords' ad is ad123. The ad is    physically hosted at ad.umber.com or at a Content Delivery Network    CDN 1376-   2. User requests the web page at cnn.com 1377-   3. As the user request goes out, the UBP monitors the IP address of    the user and retrieves the parameters associated with this user 1378-   4. The content server returns the HTML response to the user with an    embedded link pointing to an ad on ad.umber.com 1379-   5. The browser on the device makes a request to ad.umber.com to    retrieve the ad. The request arrives at ad.umber.com from the user's    device with the original IP address (since the UBP is sitting within    the carrier network). 1380-   6. The ad server in the UBP queries the UBP for parameters for the    IP address 1381-   7. The UBP returns the parameters characterizing the request (e.g.    age, demographics, location, behavior history, etc.) 1382-   8. The UBP then generates a redirect message to the ad server with    the associated parameters 1383-   9. The client requests the ad from the ad server with the parameters    1384-   10. The Ad server returns the ad image 1385-   11. The browser displays the originally requested web page with the    appropriate ad embedded in the page 1386.

Because ad.umber.com is preferably in the carrier network, it has accessto the IP address and can hence pass the required behavioral informationto the ad selection logic. The logic itself could be managed by the UBPor by a 3^(rd) party ad server. This approach allows a content providerto just point its ad requests to ad.umber.com, which then either sendsthe ad if it has the ad logic embedded in it, or points to the adserver.

One additional design that has to be brought into this system is thatall mobile networks may not have a UBP. From a consistency perspectivefor content providers, it is important that the design work even forusers that request the content page from such networks.

The overall system architecture for that is shown in FIG. 14. The UMP1402 is deployed in carrier networks. The UBP 1400 is in the Internet,along with ad director ad.xyz.com 1404

-   1. When operators have the UMP 1402 deployed, the UMP registers IP    addresses for the users it sees with the umber broker 1400-   2. The content partner 1410 points ads to ad.umber.com 1404, which    is hosted at a public place so that it can be accessed from any    carrier-   3. The user 1420 requests a page 1430 at the content partner site,    which returns a pointer 1440 to ad.umber.com-   4. The ad request goes to ad.umber.com 1440. The ad.umber.com server    then determines which provider the ad request is coming from (this    is possible even if the actual request is proxied at the mobile    operator)-   5. If the request comes from a carrier network that has a UBP    deployed, the request is redirected to the UBP 1400 and the rest of    the sequence follows as described earlier in FIGS. 13E and F-   6. If the request comes from a network that does not have a UBP,    then ad.umber.com either returns an ad itself based on limited    information it has or it redirects the request to an ad server.

Note that this approach works assuming that mobile pages are deliveredseparately from the content provider, i.e. non-mobile page requestsdon't come to Umber. In case even non-mobile requests come to thead.umber.com server, the server can detect whether or not the user agentis mobile and then pass the request to a non-mobile ad server.

FIG. 15 shows the same example as in FIG. 13A with the difference thatit has an integrated ad serving platform. In this case, the ad selectioncode is with the same platform 1530.

Using Mobile Info for Optimizing PC Ads

While the preferred embodiment of the invention has described anapproach to optimize mobile ads based on mobile behavior, it is alsopossible to optimize non-mobile ads based on mobile information. Theapproach is shown in FIG. 16.

In this approach, the user's mobile behavior is preferably linked to aspecific PC via the mobile operator's portal

-   1. User goes to mobile operator's web site. This could be to pay a    bill, or through a SMS or message sent by the operator, directing    the user to the operator's home page. The user provides a phone    number, either as part of entering the user's account or through an    operator query 1610-   2. The Operator's web page requests Umber to create a cookie for the    user's phone number 1611-   3. UBP returns a cookie to the web site 1612-   4. A cookie is setup on the user's PC 1613. (Note that to respect    the user's privacy, this cookie does not contain the user's phone    number, but is a masked version of that data.)-   5. As the user proceeds with mobile specific transactions, the UBP    monitors the user and updates the subscriber profile with behavioral    information 1614-   6. The operator/UBP sets up a relationship with advertisers that    want to use the mobile information for optimizing PC based    transactions 1615-   7. In parallel, content providers set up a relationship with    advertisers—this is the usual process and is done independently of    UBP or the mobile operator. The advertiser could offer premium    advertising services to content partners that want to behaviorally    target the ads. As part of this premium relationship, the content    provider agrees to put a piece of code in the page where the ad is    requested advertiser.com 1616-   8. The user requests a web page from the PC—the web site belongs to    one of the content providers that have signed up with this    mobile-targeted advertising service 1617-   9. The page returned from the content provider includes pointer to    the ad server to retrieve the ad and a request to pass the cookie    1618-   10. The PC browser returns the cookie to advertiser.com 1619-   11. Advertiser requests UBP for parameters associated with the    cookie 1620-   12. UBP returns the parameters for the user associated with the    cookie 1621-   13. Advertiser selects appropriate ad and passes image to the    browser 1622-   14. Browser displays the originally requested web page, with the    targeted ad embedded into it 1623.

As described earlier, the preferred approach is to tie the PC to theuser's phone number (through the operator portal), inserting the cookieassociated with this user, and returning mobile behavioral informationwhen the user goes to an associated content site.

While this specific approach shows how mobile behavior can be used toenrich PC advertising, those skilled in the art can imagine that thisapproach can also be used to enhance other media of advertising throughsuch cross-media information. Examples include enhancing IPTV or TVadvertising.

The previous discussion showed how ads can be inserted into web pages.The technology described here is not limited to web, but can be used tooptimize ads in video, voice, etc. These approaches are discussed next.

b. Insertion into Video Applications

FIG. 17 shows the insertion of information with a video application. Theapproach is similar to the web scenario in that the server queries theUBP for targeting info. A client 1704 requests video from a server 1702.The request passes through routers 1706 (e.g. a GGSN). The UBP monitorsthe requests and determines the user's profile. The video server, onreceiving the request, queries the ad server 1709 for an ad. The adserver in turn queries the optimization module in the UBP 1708 for theprofile info and determines the best ad. The ad is returned to the videoserver, which in turn inserts the ad and delivers the content with theembedded ad.

Since video formats can vary a lot, the ad selection and insertionprocess is slightly involved. Specifically, the ad server selects theright ad based on the profile in step 1710 (e.g. a Ford XYZ ad). Thevideo server determines the format of the content (resolution, encodingscheme, etc.) in step 1720. For the selected ad, the appropriate formatof the ad is then selected in step 1730 (e.g. Ford XYZ ad in format mpegfor resolution QCIF). This ad image is then concatenated to the video instep 1740. The full video with the embedded ad is then served in step1750.

FIG. 18 shows insertion with an embedded cache. A cache basedapplication comprises of the UBP with a local cache. The cache hasinternal information about the user request based on the parameters andwhen serving the content out of the cache it can insert the appropriatead. This approach applies to video as well as other content.

Caching for video is being considered in mobile networks foroptimization. In this case, serving the ad becomes more involved. Theclient 1802 requests a video from a video server 1804, which could flowthrough a router 1805. The content could be designed to be cached. Sothe router could request the content to the Umber Cache (1806). Ifcontent is cached, the cache could serve the content. If it servescached content, while serving the cached content, the ad optimizationmodule 1807 retrieves the user profile and selects the appropriate adfrom the ad server 1808. The UCP then concatenates the ad and deliversit to the user. Appropriate format selection of the ad could be donesimilar to the approach used in FIG. 17. If the content is not cached,the content server serves the content with an ad and the cache cachesthe content for subsequent accesses.

c. Insertion into Messaging Applications

FIG. 19 shows integration with SMS applications. In (a), the ad networkis associated with the UBP. The SMSC sends a request to the UBP with theuser mobile number. The UBP computes targeting parameters and selectsthe appropriate ad, which it sends to the SMSC for insertion. In (b),the SMSC contacts the ad network, which in turn queries the UBP. The UBPprovides targeting information so that the ad network can select theappropriate ad.

Approach 1 (FIG. 19A)

-   1. SMS Arrives at SMSC 1910-   2. SMSC requests Ad from UMP through mobile number 1920-   3. UMP MBT determines user <tags> and appropriate ad is selected and    ad text is returned to SMSC 1925-   4. SMSC inserts text into SMS and SMS with inserted ad is delivered    to mobile 1930.

Approach 2 (FIG. 19B)

-   1. SMS Arrives at SMSC 1910-   2. SMSC requests Ad from Ad Network by passing Mobile #1940-   3. Ad network passes phone number to MBT module 1944-   4. MBT returns <Tags> characterizing user, Ad network selects    appropriate ad, and Ad network returns text to SMSC 1948-   5. SMSC inserts text into SMS and SMS with inserted ad is delivered    to mobile 1930.    d. Insertion into Generic Applications

FIG. 20 shows integration with generic applications through an API. Thisis an example where a generic application needs to insert ads. In thiscase, the application 2010 has an API that makes a call to an ad serverto select the right ad. As shown in FIG. 20-A, the ad can be served bythe UBP 2020, which retrieves the targeting information and selects thead 2030. Alternatively, as shown in FIG. 20-B, the ad can be served byan external ad network 2040 that uses the UBP 2050 to determine thetargeting information before selecting the ad.

e. Insertion into WAP Gateways

FIG. 21 shows integration with inline products such as proxy servers orWAP gateways. In this case, the web request goes to the Internet as instep 2110. In parallel, the gateway queries the ad selection engine forthe ad to be inserted, 2120. The ad selection engine then passes the IPaddress and information to the broker in step 2130. The broker maintainsa mapping of IP address and phone number, retrieves the appropriateprofile, and provides the information to the ad selection process. Thead selection process then selects the appropriate ad, which getsinserted before the page is displayed back to the user in step 2140.Alternatively, the gateway can insert the targeting parameters inline tosend to the advertiser outside the network.

f. Insertion into Voice Applications

It is possible to use the targeting capability to provide target ads tovoice applications such as ringback tones. As an example of ringbacktones, consider the following example: When user A calls user B, user Ahears a specific caller ringback tone that user B has designated.However, it is possible to provide a targeted ringback tone containingan appropriate Ad. In this case, user A calls user B as in step 2210.The switch generates a trigger 2220 to the Caller Back Ring Tone (CRBT)server. The CRBT server in turn contacts the broker 2230 with the user'sphone number. The brokering platform returns a profile 2240 for thisuser. The CRBT platform then selects an ad appropriate to the user basedon the profile and plays out the appropriate ad 2250. The caller A hearsthe targeted tone 2260 and proceeds with the call. This analogy can beextended to providing a message prior to any voice applications.

Operation of a Carrier-Centric Ad Exchange

The UBP solution can also be used by a carrier to develop an ad exchangeor an exchange of ad networks. FIG. 23 shows the concept that a mobileoperator 2380 can build subscriber profiles by using informationcollected by Monitors 2310. When serving content to mobile users, it canprovide an ad request to a set of ad networks (2330, 2340) or toindividual advertisers 2350 for the specific user. The network thatresponds with the best bid can be used to select the ad. The carrierwould then work with publishers 2360 to provide the actual ad. Thebrokering platform 2370 builds the profiles of users and then uses theprofiles to request and furnish the appropriate ad in real-time.

Fit within Existing Ad Server Platforms

The technology provided by the UBP fits into existing Ad serverarchitectures. FIG. 24 shows a typical ad server that includes inventorymanagement (2430), collection of Ad (2410) and Content inventory (2420),and campaign management (2440), along with reporting and settlement(2450). Insertion of the ad itself could be done by the ad server or byany other technology. The UBP fits into such an architecture byproviding four different capabilities

-   1. Targeting Logic (2460): The Ad server can provide a specific    campaign description to the UBP, which can decide which users map to    that profile. This enables the campaign to be directed to the    targeted list of users-   2. Enhancing Subscriber Profile (2490): The UBP through its    real-time data collection method can continuously update the    subscriber profile. This information can be used by the campaign    manager to select users that map the profile-   3. Enhanced insertion (2470): In another approach, the ad insertion    logic can query the UBP in real-time to provide parameters for a    specific user so that the ad can be targeted in real time. The    specific approaches described earlier in this document outline how    this can be done without changing existing applications or requiring    new software-   4. In addition, the UBP can also provide additional auditing and    measurement of user responses for reporting and settlement purposes    (2450).

Client-Based Architecture

In addition to the network based architecture described earlier, it isalso possible to provide a similar behavioral targeting solution throughdistributed agents. Such a solution will likely be deployed outside thecarrier network. However, it is also possible to deploy this within thecarrier network, or as a hybrid approach where some phones have such aclient and other phones do not.

In this approach, client software is distributed to phones. The clientis basically a shim, i.e. a brokering client on the handset, and doesnot typically involve the user and is non-intrusive. The client can bedistributed to phones in one of several ways: (a) can be bundled withsome applications (e.g. games, or video applications) (b) can be bundledwith the OS by partnering with device vendors (c) can be explicitlydownloaded by users (d) in the case of carrier involvement, it can be afirmware upgrade to the device.

The role of the client software is to collect some information on behalfof the UBP.

The UBP platform is similar to the architecture shown earlier—a new datacollection adapter is added, which receives information from clients.

The UBP ecosystem involves partnering with content providers/applicationproviders/ad networks that wish to receive targeted information. Thecontent provider/application provider inserts additional software ontheir servers to query the UBP for information as needed.

Set Up:

-   1. Shims are distributed to phones. Optionally, the shim can query    the user to provide demographic information through an opt-in. The    user may opt-in for several reasons, including being part of a    specific application or because they may receive promotions or    targeted information. The shim registers with the UBP, which creates    an ID for the device-   2. Content providers sign up for targeting service and include code    to query the UBP.

FIG. 25 shows the Client-based Targeting Operational flow:

-   1. User starts a new session in step 2510 (a session could be an    application or a web session). The shim generates a temporary    session ID and sends that to the UBP. While the UBP has the static    identifier, the temporary session ID is used for the session to    exchange information with content partners. The shim also sends any    other data it can collect, including location, time, etc.;-   2. The user starts accessing the desired application. Depending on    the application, the shim inserts the temporary session ID in step    2520. For instance, in a gaming application, or a video application,    the session ID is passed to the server. In the case of a web    application, the session ID is passed embedded in the URL;-   3. Due to the partnership, the content server knows where to receive    the identity information and its semantics. The server queries the    UBP in step 2530 for information on this user. The UBP responds with    relevant information, depending on the policy and application. This    information could be user info, keywords from participating sites,    location data, etc. Alternatively, the UBP could also instruct the    shim to pass specific information in-line to the server;-   4. The server then responds to this information and either generates    targeted content or ads and uses it in the return response in step    2540.

Thus it can be seen that the analytics and information brokering issimilar whether the data is collected from the network or from clients.The differences in the client based approach lie in:

-   1. Mechanism for collecting information: The information is    collected from agents on devices. Other sources of information can    also be added to this, such as server logs or real-time data. In a    hybrid approach, the carrier data can also be provided to this-   2. Ownership of information: The UBP owns the information and can    share it effectively with partners based on policies. For instance,    keyword information across select CPs can be shared based on groups.

Usage Sequence

The typical sequence for using the UBP is shown in FIG. 26

-   1. An application, operator, or ad network specifies the type of    campaign to run 2610—what demographics to target, and what    information is relevant (Location and content history, for instance)-   2. This information is passed on to the Monitor. UMP in step 2620    tracks all requests to this particular application (through    protocol, destination address, etc.)-   3. As user requests go to this application, UBP in step 2630    identifies users that belong to this category (e.g. specific    demographics)-   4. UBP in step 2640 determines parameters appropriate to the    application being targeted and collects targeting info for selected    users-   5. UBP in step 2650 determines privacy policies. As information is    being passed, UBP also tracks which users have received how many    targeted ads so far and can maintain a frequency cap. It will also    ensure privacy policies before sharing information-   6. In real-time, for users that belong to this category and are    accessing this information, UBP in step 2660 passes on relevant    information (e.g. location and usage history vector) to the    application through one of the different approaches described    earlier-   7. UBP monitors in step 2670 overall what information was shared,    how much was shared etc. for auditing privacy. UBP can also monitor    any clickthroughs that go to specific ads in the targeted ads to    provide the operator with an audit for settlement purposes-   8. UBP in step 2680 generates reports on the overall info exchanged,    effectiveness of targeting, etc.

While the above describes a particular order of operations performed bya given embodiment of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

While the present invention has been described in the context of amethod or process, the present invention also relates to apparatus forperforming the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may comprise ageneral-purpose computer selectively activated or reconfigured by acomputer program stored in the computer. Such a computer program may bestored in a computer readable storage medium including, withoutlimitation, any type of disk including optical disks, CD-ROMs, andmagnetic-optical disks, read-only memory (ROM), random access memory(RAM), magnetic or optical cards, or any type of media suitable forstoring electronic instructions.

While given components of the system have been described separately, oneof ordinary skill also will appreciate that some of the functions may becombined or shared in given instructions, program sequences, codeportions, and the like.

What is claimed is:
 1. In a mobile data network, a method for sharinguser profiles with content servers so they may select content responsiveto a user profile, said method comprising: providing a store of userprofiles, each profile associating profile information with at least oneof a source IP address and a phone number for a mobile device associatedwith a user, said profile information being indicative of at least saiduser and said user's usage of said mobile data network; detecting on themobile data network a user request for a transaction with a contentprovider; inspecting the user request to retrieve at least one of asource IP address or a phone number for a mobile device issuing thetransaction request; using the retrieved source IP address or phonenumber to retrieve a corresponding profile from the store; in responseto a profile request, applying predetermined opt-out rules to determinewhether at least a subset of said retrieved profile may be provided inresponse to the request; and in response to said profile request,providing at least a subset of said corresponding profile informationwith masked user identity information.